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DETAILED ACTION 

Response to Arguments 

Applicant's arguments filed 03/02/2009 have been fully considered but they are not 
persuasive. 

For claim 1 and similarly claims 23, 27, 31, 32, the applicant argues that the insertion of 
the EOS token only takes place when it is determined that the packet is the last packet in 
the subaction and that such teaching does not correspond to a determination that there is 
no packet of the second type. As shown in figures 3 and 4, it is determined if there is a 
packet to be sent during the current subaction. If it is determined that there is no more 
packets to be sent during this subaction (figure 3, 122 and figure 4, 162; col 4 line 10- 
25), a EOS token is placed into the transmission. The technique in figures 3 and 4 is 
applied to any type of packet (s) in the subaction including asynchronous packets, that do 
not require ACKs to be transmitted (see col 2 lines 1-20 "asynchronous ackless. . . 
subactions. . .asynchronous stream. . ." and col 5 line 20-35 "ackless packet"; fig 5; 200). 
Thus the examiner takes the stance that Hauck discloses "if there is no packet of the 
second type to be sent, then concatenating a token" where a determination is made if a 
concatenated packet was the last one of the subaction (ie. no packet (including 
asynchronous packets during asynchronous ackless subaction) to be sent) and based on 
this determination a EOS token is placed in the subaction. Such a determination matches 
and is not excluded by the claim language "if there is no packet of the second type to be 
sent". 
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Further, the applicant argues that "the Examiner's interpretation that "an EOS token" is 
equivalent to "a bogus ack" packet" (or false acknowledgment packet) is incorrect and 
not equivalent. It is pointed out the the applicant, the examiner never alleged that the 
EOS token is a ACK or bogus ACK packet. The office action clearly indicated that 
Hauck discloses concatenating a token and that an ACK packet is taught by Duckwall 
and further that the rejection is based on a combination Hauck and Duckwall. In 
response to applicant's arguments against the references individually (i.e. Hauck), one 
cannot show nonobviousness by attacking references individually where the rejections 
are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 
(CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). The 
applicant has not presented arguments how the combination of Hauck and Duckwall does 
not disclose the claimed language. 

For claim 18 and similarly claims 26, 30 38 and 49, the applicant presents similar 
arguments regarading the EOS token not being equivalent to a "bogus ack" packet. The 
same / similar reasons applies to this arguments as the one explained above. 



Claim Rejections - 35 USC §103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patcntabi I it\ shall not be negatived by the 
manner in which the invention was made. 
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The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 
(1966), that are applied for establishing a background for determining obviousness under 35 
U.S.C. 103(a) are summarized as follows: 

1 . Determining the scope and contents of the prior art. 

2. Ascertaining the differences between the prior art and the claims at issue. 

3. Resolving the level of ordinary skill in the pertinent art. 

4. Considering objective evidence present in the application indicating obviousness 
or nonobviousness. 

1. Claim 1, 18, 20, 31, 38, 40, 43, 49 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Hauck et al. (US 6,356,558) in view of Duckwall (US 5,495,481) 

For claim 1, Hauck discloses A method (see fig 3, 4) for administering a serial bus (see 
fig 2), the bus facilitating communication between node devices connected to the bus and 
communicating over the bus (see fig 1 ; Node, serial bus; fig 5) in the form of packetized 
communication (see fig 5; packet) between said node devices (see fig 1; node, serial bus), 
wherein a first type of packet 

comprises asynchronous packets characterized by the absence of a requirement that ack 
packet be sent in response to transmission of a packet of the first type (see col 2 lines 1- 
20 "asynchronous ackless. . . subactions. . .asynchronous stream. . ." and col 5 line 20-35 
"ackless packet"; fig 5; 200), wherein a second type of packet comprises asynchronous 
packets (see col 5 line 20-35 "asynchronous packets" ; col 5 line 25-35 "concatenated 
packet to be acknowledged"), the method comprising: 

if there is a packet of the second type to be sent (see fig 4; 156, YES; and fig 5; 210-214), 
then concatenating the packet of the second type (see fig 4; 160 and fig 5; 210-214) to a 



Application/Control Number: 10/728,185 Page 5 

Art Unit: 2416 

plurality of packets of the first type (see col 2 lines 1-20 "asynchronous ackless. . . 
subactions... asynchronous stream..." and col 5 line 20-35 "ackless packet"; fig 5; 200) 
and sending the plurality of packets of the first type (see col 2 lines 1-20 "asynchronous 
ackless. . . subactions. . .asynchronous stream. . ." and col 5 line 20-35 "ackless 
packet. . .process continue up the tree. . .multiple concatenation of asynchronous 
packets. . ."; fig 5; 200) followed by the concatenated packet of the second type (see fig 4; 
160 and fig 5; 210-214); and 

if there is no packet of the second type (sec col 5 line 20-35 "asynchronous packets" ; col 
5 line 25-35 "concatenated packet to be acknowledged") to be sent (see fig 3; 122, 126, 
YES and fig 4; 162 YES), then concatenating a token (see fig 3; 128; fig 4; 164; col 4 1. 
15-35 "insertion of the EOS token"; col 2 lines 45-60 "attaching. . .token to packet that 
are the last packet of the subaction"; col 3 line 60-67 "attached immediately after the 
EOD token, .number of idel characters after the EOD token") to the plurality of packets of 
the first type (see col 2 lines 1-20 "asynchronous ackless. . . subactions. . .asynchronous 
stream. . ." and col 5 line 20-35 "ackless packet. . .process continue up the tree. . .multiple 
concatenation of asynchronous packets. .."; fig 5; 200) and sending the plurality of 
packets of the first type (see col 2 lines 1-20 "asynchronous ackless. . . 
subactions. . .asynchronous stream. . ." and col 5 line 20-35 "ackless packet. . .process 
continue up the tree. . .multiple concatenation of asynchronous packets. . ."; fig 5; 200) 
followed by the concatenated token (see fig 3; 128; fig 4; 164; col 4 1. 15-35 "insertion of 
the EOS token"; col 2 lines 45-60 "attaching. . .token to packet that are the last packet of 
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the subaction"; col 3 line 60-67 "attached immediately after the EOD token.. number of 
idel characters after the EOD token"). 

For claim 18, Hauck discloses A method (see fig 3, 4) for administering a serial bus (see 
fig 2), the bus facilitating communication between node devices connected to the bus and 
communicating over the bus (see fig 1 ; Node, serial bus; fig 5) in the form of packetized 
communication (see fig 5; packet) between said node devices (see fig 1; node, serial bus), 
wherein a first type of packet 

comprises asynchronous packets characterized by the absence of a requirement that an 

ack packet be sent in response to transmission of a packet of the first 

type (see col 2 lines 1-20 "asynchronous ackless... subactions... asynchronous stream..." 

and col 5 line 20-35 "ackless packet"; fig 5; 200), wherein a second type of packet 

comprises asynchronous packets (see col 5 line 20-35 "asynchronous packets" ; col 5 line 

25-35 "concatenated packet to be acknowledged"), the method comprising: 

receiving (see col 2 line 35j-40 "receiving a packet" and fig 5; 200-202) a packet of the 

first type (see col 2 lines 1-20 "asynchronous ackless... subactions... asynchronous 

stream. . ." and col 5 line 20-35 "ackless packet. . .process continue up the tree. . .multiple 

concatenation of asynchronous packets. .."; fig 5; 200); 

determining that there are no packets of the second type (see col 5 line 20-35 

"asynchronous packets" ; col 5 line 25-35 "concatenated packet to be acknowledged") to 

be sent (see fig 3; 122, 126, YES and fig 4; 162 YES; and col 20-35 "ackless packet"; 

case where we have ackless packets to concatenate); 
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if fly-by concatenation is permitted (see col 4 1. 40 - 65 "If concatenation is allowed...") 
then concatenating a token (see fig 3; 128; fig 4; 164; col 4 1. 15-35 "insertion of the EOS 
token"; col 2 lines 45-60 "attaching. . .token to packet that are the last packet of the 
subaction"; col 3 line 60-67 "attached immediately after the EOD token.. number of idel 
characters after the EOD token") to the received packet (see fig 4; 160; 167, 168) and 
sending the received packet (see fig 4; 160; 167, 168) and the token (see fig 3; 128; fig 4; 
164; col 4 1. 15-35 "insertion of the EOS token"; col 2 lines 45-60 "attaching. . .token to 
packet that are the last packet of the subaction"; col 3 line 60-67 "attached immediately 
after the EOD token. .number of idcl characters after the EOD token"); and 
if fly-by concatenation is not permitted then sending the received packet (see col 4 1. 40- 
55 "concatenation is not permitted. . .packet is repeated to all non-receiving 
ports. . .arbitration commences"), arbitrating for 

the bus (see col 4 1. 40-55 "concatenation is not permitted. . .packet is repeated to all non- 
receiving ports. . .arbitration commences"), and sending a token (see col 4 1. 4 — 55 "last 
toke is a EOS token. . .concatenation is not permitted. . .packet is repeated. . .") 
For claim 20, Hauck et al. teach wherein arbitrating for control of the bus is 
performed by PHY hardware (see column 4 lines 1-4, the PHY can manipulate 
arbitration line state; see column 3 lines 18-21, the arbitration state machine can be 
implemented in the PHY). 

For claim 31 and similarly claim 43, Hauck discloses A method (see fig 3, 4) for 
administering a data bus (see fig 2), the bus facilitating 

communication between node devices communicating over the bus (see fig 1 ; Node, 
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serial bus; fig 5) using at least a first type type (see col 2 lines 1-20 "asynchronous 
ackless. . . subactions. . .asynchronous stream. . ." and col 5 line 20-35 "ackless packet"; fig 
5; 200) and second type of asynchronous packet (see col 5 line 20-35 "asynchronous 
packets" ; col 5 line 25-35 "concatenated packet to be acknowledged"), the first type of 
packet not requiring that an acknowledgement packet be sent in response to transmission 
of such first type of packet (see col 2 lines 1-20 "asynchronous ackless. . . 
subactions. . .asynchronous stream. . ." and col 5 line 20-35 "ackless packet"; fig 5; 200), 
the method comprising: 

if there is a packet of the second type to be sent (see fig 4; 156, YES; and fig 5; 210-214), 
then concatenating the packet of the second type (see fig 4; 160 and fig 5; 210-214) to a 
plurality of packets of the first type (see col 2 lines 1-20 "asynchronous ackless. . . 
subactions... asynchronous stream..." and col 5 line 20-35 "ackless packet"; fig 5; 200) 
and sending the plurality of packets of the first type (see col 2 lines 1-20 "asynchronous 
ackless... subactions... asynchronous stream..." and col 5 line 20-35 "ackless 
packet. . .process continue up the tree. . .multiple concatenation of asynchronous 
packets. . ."; fig 5; 200) followed by the concatenated packet of the second type (see fig 4; 
160 and fig 5; 210-214); and 

if there is no packet of the second type (see col 5 line 20-35 "asynchronous packets" ; col 
5 line 25-35 "concatenated packet to be acknowledged") to be sent (see fig 3; 122, 126, 
YES and fig 4; 162 YES), then concatenating a token (see fig 3; 128; fig 4; 164; col 4 1. 
15-35 "insertion of the EOS token"; col 2 lines 45-60 "attaching. . .token to packet that 
are the last packet of the subaction"; col 3 line 60-67 "attached immediately after the 



Application/Control Number: 10/728,185 Page 9 

Art Unit: 2416 

EOD token, .number of idel characters after the EOD token") to the plurality of packets of 
the first type (see col 2 lines 1-20 "asynchronous ackless. . . subactions. . .asynchronous 
stream. . ." and col 5 line 20-35 "ackless packet. . .process continue up the tree. . .multiple 
concatenation of asynchronous packets. . ."; fig 5; 200) and sending the plurality of 
packets of the first type (see col 2 lines 1-20 "asynchronous ackless. . . 
subactions. . .asynchronous stream. . ." and col 5 line 20-35 "ackless packet. . .process 
continue up the tree. . .multiple concatenation of asynchronous packets. . ."; fig 5; 200) 
followed by the concatenated token (see fig 3; 128; fig 4; 164; col 4 1. 15-35 "insertion of 
the EOS token"; col 2 lines 45-60 "attaching. . .token to packet that are the last packet of 
the subaction"; col 3 line 60-67 "attached immediately after the EOD token.. number of 
idel characters after the EOD token") 

For claim 38 and similarly claim 49, Hauck discloses A method for administering (see 
fig 3, 4)a data bus (see fig 2), the bus facilitating 

communication between node devices communicating over the bus (see fig 1 ; Node, 
serial bus; fig 5) using at least a first type type (see col 2 lines 1-20 "asynchronous 
ackless. . . subactions. . .asynchronous stream. .." and col 5 line 20-35 "ackless packet"; fig 
5; 200) and second type of asynchronous packet (see col 5 line 20-35 "asynchronous 
packets" ; col 5 line 25-35 "concatenated packet to be acknowledged"), the first type of 
packet having no requirement that a response packet be sent in response to transmission 
thereof (see col 2 lines 1-20 "asynchronous ackless. . . subactions. . .asynchronous 
stream. . ." and col 5 line 20-35 "ackless packet"; fig 5; 200), the method comprising: 
receiving (see col 2 line 35j-40 "receiving a packet" and fig 5; 200-202) a packet of the 
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first type (see col 2 lines 1-20 "asynchronous ackless. . . subactions. . .asynchronous 
stream. . ." and col 5 line 20-35 "ackless packet. . .process continue up the tree. . .multiple 
concatenation of asynchronous packets..."; fig 5; 200); 
determining that there are no packets of the second type (see col 5 line 20-35 
"asynchronous packets" ; col 5 line 25-35 "concatenated packet to be acknowledged") to 
be sent (see fig 3; 122, 126, YES and fig 4; 162 YES; and col 20-35 "ackless packet"; 
case where we have ackless packets to concatenate); 

if concatenation is permitted (see col 4 1. 40 - 65 "If concatenation is allowed...") 
concatenating a token (see fig 3; 128; fig 4; 164; col 4 1. 15-35 "insertion of the EOS 
token"; col 2 lines 45-60 "attaching. . .token to packet that are the last packet of the 
subaction"; col 3 line 60-67 "attached immediately after the EOD token. .number of idel 
characters after the EOD token") to the received packet (see fig 4; 160; 167, 168) and 
sending the received packet (see fig 4; 160; 167, 168) and the token (see fig 3; 128; fig 4; 
164; col 4 1. 15-35 "insertion of the EOS token"; col 2 lines 45-60 "attaching. . .token to 
packet that are the last packet of the subaction"; col 3 line 60-67 "attached immediately 
after the EOD token.. number of idel characters after the EOD token"); and 
if concatenation is not permitted , sending the received packet (see col 4 1. 40-55 
"concatenation is not permitted. . .packet is repeated to all non-receiving 
ports. . .arbitration commences"), arbitrating for 

the bus (see col 4 1. 40-55 "concatenation is not permitted. . .packet is repeated to all non- 
receiving ports. . .arbitration commences"), and sending a token (see col 4 1. 4 — 55 "last 
toke is a EOS token. . .concatenation is not permitted. . .packet is repeated. . .") 
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For claim 40, Hauck et al. teach wherein arbitrating for control of the bus is 
performed by PHY hardware (see column 4 lines 1-4, the PHY can manipulate 
arbitration line state; see column 3 lines 18-21, the arbitration state machine can be 
implemented in the PHY). 

For claim 43 and 49, Hauck discloses a node device (see fig 1 and fig 2; node). 

Hauck is silent about: 

For claim 1,18 a bogus ack packet. 

For claim 31 and 43, a false acknowledgement packet. 

For claim 38 and 49, a false response packet. 

Duckwall from the same field of endeavor discloses the following features: 
For claim 1,18, Duckwall discloses a bogus ack packet (see col 6 lines 20-50 
"According to the P1394 standard, acknowledge packets are eight bit long. . .data packets 
are at least sixty-four bits long.. .count the number of bits.. .discriminate between data 
packets and acknowledge packets... equal to eight, the node identifies that an 
acknowledge packet has been transmitted. . .") 

For claim 31 and 43, Duckwall discloses a false acknowledgement packet (see col 6 lines 
20-50 "According to the P1394 standard, acknowledge packets are eight bit long. . .data 
packets are at least sixty-four bits long.. .count the number of bits. ..discriminate between 
data packets and acknowledge packets. . .equal to eight, the node identifies that an 
acknowledge packet has been transmitted. . ."). 

For claim 38 and 49, Duckwall discloses a false response packet (see col 6 lines 20-50 
"According to the P1394 standard, acknowledge packets are eight bit long. . .data packets 
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are at least sixty-four bits long. ..count the number of bits... discriminate between data 
packets and acknowledge packets. . .equal to eight, the node identifies that an 
acknowledge packet has been transmitted. . ."). 

It would have been obvious to one of the ordinary skill in the art at the time of the 
invention to modify / combine / substitute the system of Hauck by using the above recited 
features, as taught by Duckwall, in order to provide EOS token which will be recognized 
by node devices explicitly since acknowledgement and data packets are distinctly 
recognized in 1394 systems (see Duckwall col 6 and Hauck col 2 lines 45-60). 

2. Claims 23, 26, 27, 30, are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Hauck et al. (US 6,356,558) in view of Duckwall (US 5,495,481) and Henry et al (US 
2004/0151153) 

For claim 23, Hauck discloses administer (see fig 3, 4) a serial bus (see fig 2), the bus 
facilitating communication between node devices connected to the bus and 
communicating over the bus (see fig 1 ; Node, serial bus; fig 5) in the form of packetized 
communication (see fig 5; packet) between said node devices (see fig 1; node, serial bus), 
wherein a first type of packet 

comprises asynchronous packets characterized by the absence of a requirement that ack 
packet be sent in response to transmission of a packet of the first type (see col 2 lines 1- 
20 "asynchronous ackless... subactions... asynchronous stream..." and col 5 line 20-35 
"ackless packet"; fig 5; 200), wherein a second type of packet comprises asynchronous 
packets (see col 5 line 20-35 "asynchronous packets" ; col 5 line 25-35 "concatenated 
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packet to be acknowledged"), by performing the acts of: 

if there is a packet of the second type to be sent (see fig 4; 156, YES; and fig 5; 210-214), 
then concatenating the packet of the second type (see fig 4; 160 and fig 5; 210-214) to a 
plurality of packets of the first type (see col 2 lines 1-20 "asynchronous ackless. . . 
subactions. . .asynchronous stream. . ." and col 5 line 20-35 "ackless packet"; fig 5; 200) 
and sending the plurality of packets of the first type (see col 2 lines 1-20 "asynchronous 
ackless... subactions... asynchronous stream..." and col 5 line 20-35 "ackless 
packet. . .process continue up the tree. . .multiple concatenation of asynchronous 
packets. . ."; fig 5; 200) followed by the concatenated packet of the second type (see fig 4; 
160 and fig 5; 210-214); and 

if there is no packet of the second type (see col 5 line 20-35 "asynchronous packets" ; col 
5 line 25-35 "concatenated packet to be acknowledged") to be sent (see fig 3; 122, 126, 
YES and fig 4; 162 YES), then concatenating a token (see fig 3; 128; fig 4; 164; col 4 1. 
15-35 "insertion of the EOS token"; col 2 lines 45-60 "attaching. . .token to packet that 
are the last packet of the subaction"; col 3 line 60-67 "attached immediately after the 
EOD token, .number of idel characters after the EOD token") to the plurality of packets of 
the first type (see col 2 lines 1-20 "asynchronous ackless. . . subactions. . .asynchronous 
stream. . ." and col 5 line 20-35 "ackless packet. . .process continue up the tree. . .multiple 
concatenation of asynchronous packets. . ."; fig 5; 200) and sending the plurality of 
packets of the first type (see col 2 lines 1-20 "asynchronous ackless. . . 
subactions. . .asynchronous stream. . ." and col 5 line 20-35 "ackless packet. . .process 
continue up the tree. . .multiple concatenation of asynchronous packets. . ."; fig 5; 200) 
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followed by the concatenated token (see fig 3; 128; fig 4; 164; col 4 1. 15-35 "insertion of 
the EOS token"; col 2 lines 45-60 "attaching. . .token to packet that are the last packet of 
the subaction"; col 3 line 60-67 "attached immediately after the EOD token.. number of 
idel characters after the EOD token"). 

For claim 26 and similarly claim 30, Hauck discloses administers (see fig 3, 4) a serial 
bus (see fig 2), the bus facilitating communication between node devices connected to the 
bus and communicating over the bus (see fig 1 ; Node, serial bus; fig 5) in the form of 
packetized communication (see fig 5; packet) between said node devices (see fig 1; node, 
serial bus), wherein a first type of packet 

comprises asynchronous packets characterized by the absence of a requirement that an 
ack packet be sent in response to transmission of a packet of the first 
type (see col 2 lines 1-20 "asynchronous ackless... subactions... asynchronous stream..." 
and col 5 line 20-35 "ackless packet"; fig 5; 200), wherein a second type of packet 
comprises asynchronous packets (see col 5 line 20-35 "asynchronous packets" ; col 5 line 
25-35 "concatenated packet to be acknowledged"), by performing the acts of: 
receiving (see col 2 line 35j-40 "receiving a packet" and fig 5; 200-202) a packet of the 
first type (see col 2 lines 1-20 "asynchronous ackless. . . subactions. . .asynchronous 
stream. . ." and col 5 line 20-35 "ackless packet. . .process continue up the tree. . .multiple 
concatenation of asynchronous packets..."; fig 5; 200); 
determining that there are no packets of the second type (see col 5 line 20-35 
"asynchronous packets" ; col 5 line 25-35 "concatenated packet to be acknowledged") to 
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be sent (see fig 3; 122, 126, YES and fig 4; 162 YES; and col 20-35 "ackless packet"; 
case where we have ackless packets to concatenate); 

if fly-by concatenation is permitted (see col 4 1. 40 - 65 "If concatenation is allowed...") 
then concatenating a token (see fig 3; 128; fig 4; 164; col 4 1. 15-35 "insertion of the EOS 
token"; col 2 lines 45-60 "attaching. . .token to packet that are the last packet of the 
subaction"; col 3 line 60-67 "attached immediately after the EOD token.. number of idel 
characters after the EOD token") to the received packet (see fig 4; 160; 167, 168) and 
sending the received packet (see fig 4; 160; 167, 168) and the token (see fig 3; 128; fig 4; 
164; col 4 1. 15-35 "insertion of the EOS token"; col 2 lines 45-60 "attaching... token to 
packet that are the last packet of the subaction"; col 3 line 60-67 "attached immediately 
after the EOD token.. number of idel characters after the EOD token"); and 
if fly-by concatenation is not permitted then sending the received packet (see col 4 1. 40- 
55 "concatenation is not permitted. . .packet is repeated to all non-receiving 
ports. . .arbitration commences"), arbitrating for 

the bus (see col 4 1. 40-55 "concatenation is not permitted. . .packet is repeated to all non- 
receiving ports. . .arbitration commences"), and sending a token (see col 4 1. 4 — 55 "last 
toke is a EOS token. . .concatenation is not permitted. . .packet is repeated. . .") 
For claim 27, Hauck discloses administers(see fig 3, 4) a data bus (see fig 2), the bus 
facilitating 

communication between node devices communicating over the bus (see fig 1; Node, 
serial bus; fig 5) using at least a first type type (see col 2 lines 1-20 "asynchronous 
ackless. . . subactions. . .asynchronous stream. . ." and col 5 line 20-35 "ackless packet"; fig 
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5; 200) and second type of asynchronous packet (see col 5 line 20-35 "asynchronous 
packets" ; col 5 line 25-35 "concatenated packet to be acknowledged"), the first type of 
packet not requiring that an acknowledgement packet be sent in response to transmission 
of such first type of packet (see col 2 lines 1-20 "asynchronous ackless. . . 
subactions. . .asynchronous stream. . ." and col 5 line 20-35 "ackless packet"; fig 5; 200), 
by performing acts of: 

if there is a packet of the second type to be sent (see fig 4; 156, YES; and fig 5; 210-214), 
then concatenating the packet of the second type (see fig 4; 160 and fig 5; 210-214) to a 
plurality of packets of the first type (see col 2 lines 1 -20 "asynchronous ackless. . . 
subactions... asynchronous stream..." and col 5 line 20-35 "ackless packet"; fig 5; 200) 
and sending the plurality of packets of the first type (see col 2 lines 1-20 "asynchronous 
ackless... subactions... asynchronous stream..." and col 5 line 20-35 "ackless 
packet. . .process continue up the tree. . .multiple concatenation of asynchronous 
packets. . ."; fig 5; 200) followed by the concatenated packet of the second type (see fig 4; 
160 and fig 5; 210-214); and 

if there is no packet of the second type (see col 5 line 20-35 "asynchronous packets" ; col 
5 line 25-35 "concatenated packet to be acknowledged") to be sent (see fig 3; 122, 126, 
YES and fig 4; 162 YES), then concatenating a token (see fig 3; 128; fig 4; 164; col 4 1. 
15-35 "insertion of the EOS token"; col 2 lines 45-60 "attaching. . .token to packet that 
are the last packet of the subaction"; col 3 line 60-67 "attached immediately after the 
EOD token, .number of idel characters after the EOD token") to the plurality of packets of 
the first type (see col 2 lines 1-20 "asynchronous ackless. . . subactions. . .asynchronous 
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stream. . ." and col 5 line 20-35 "ackless packet. . .process continue up the tree. . .multiple 
concatenation of asynchronous packets. . ."; fig 5; 200) and sending the plurality of 
packets of the first type (see col 2 lines 1-20 "asynchronous ackless. . . 
subactions. . .asynchronous stream. . ." and col 5 line 20-35 "ackless packet. . .process 
continue up the tree. . .multiple concatenation of asynchronous packets. . ."; fig 5; 200) 
followed by the concatenated token (see fig 3; 128; fig 4; 164; col 4 1. 15-35 "insertion of 
the EOS token"; col 2 lines 45-60 "attaching. . .token to packet that are the last packet of 
the subaction"; col 3 line 60-67 "attached immediately after the EOD token..number of 
idel characters after the EOD token") 

For claim 27 and similarly claim 30, Hauck discloses a node device (see fig 1 and fig 2; 
node) connected to a serial bus (see fig 1 and fig 2; node, serial bus) 
Hauck is silent about: 

For claim 23, 26, 29, 30, computer readable medium containing / comprising instructions 

which, when executed by a computer; a bogus ack packet. 

Duckwall from the same field of endeavor discloses the following features: 

For claim 23, 26, 29, 30, Duckwall discloses a bogus ack packet (see col 6 lines 20-50 

"According to the P1394 standard, acknowledge packets are eight bit long. . .data packets 

are at least sixty-four bits long. ..count the number of bits. ..discriminate between data 

packets and acknowledge packets. . .equal to eight, the node identifies that an 

acknowledge packet has been transmitted. . .") 

Henry from the same or similar field of endeavor discloses the following features: 
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For claim 23, 26, 29, 30, computer readable medium containing / comprising instructions 
which, when executed by a computer (see secton 0044 "software stack") 
It would have been obvious to one of the ordinary skill in the art at the time of the 
invention to modify / combine / substitute the system of Hauck by using the above recited 
features, as taught by Duckwall and Henry, in order to provide EOS token which will be 
recognized by node devices explicitly since acknowledgement and data packets are 
distinctly recognized in 1394 systems (see Duckwall col 6 and Hauck col 2 lines 45-60); 
in order to provide means for implementing methods / protocols via software which can 
be programmed / reprogrammed without having to change hardware. 

3. Claim 2, 3, 32, 33, 44, 45 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Hauck et al. (US 6,356,558) in view of Duckwall (US 5,495,481) as applied to claims 1/31/43 
above, and further in view of Duckwall (US 5,802,057). 

For claim 2, Hauck and Duckwall discloses the claimed invention as described above. 

Furthemore, for claim 2, 32, 44 Hauck discloses packet of the second type (see col 5 line 

20-35 "asynchronous packets" ; col 5 line 25-35 "concatenated packet to be 

acknowledged") 

Furthemore, for claim 3, Duckwall discloses the bogus ack packet (see col 6 lines 20-50 
"According to the P1394 standard, acknowledge packets are eight bit long. . .data packets 
are at least sixty-four bits long. ..count the number of bits... discriminate between data 
packets and acknowledge packets. . .equal to eight, the node identifies that an 
acknowledge packet has been transmitted. . ."). 
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Furthemore, for claim 33, 45 Duckwall discloses the false acknowledgement packet (see 

col 6 lines 20-50 "According to the P1394 standard, acknowledge packets are eight bit 

long. . .data packets are at least sixty-four bits long... count the number of 

bits... discriminate between data packets and acknowledge packets. . .equal to eight, the 

node identifies that an acknowledge packet has been transmitted. . ."). 

Hauck and Duckwall are silent about: 

For claim 2,3, 32, 33, wherein concatenating the packet is performed by link hardware. 
For claim 44. and 45 comprising link hardware adapted to concatenate the packet . 
Duckwall from the same or similar field of endeavor discloses a communication network 
with the following features: 

For claim 2,3, 32,33, Duckwall disloses wherein concatenating the packet (see col 8 lines 
30-37 "ack-concatenation") is performed by link hardware (see col 8 lines 30-37 "link 
hardware"). 

For claim 44 and 45, Duckwall disloses comprising link hardware see col 8 lines 30-37 
"link hardware") adapted to concatenate the packet (see col 8 lines 30-37 "ack- 
concatenation"). 

It would have been obvious to one of the ordinary skill in the art at the time of the 
invention to modify / combine the system of Hauck Duckwall by using the above 
features, as taught by Duckwall, in order to minimize arbitration delays (see col 3). 
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4. Claim 4,5, 19, 34, 35, 39, 46 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Hauck et al. (US 6,356,558) in view of Duckwall (US 5,495,481) as applied to claim 
1/18/31 above, and further in view of Duckwall (US 2004/0246959). 

For claim 4 and 5, Hauck and Duckwall disclose the claimed invention as described 
above. 

Furthemore, for claim 4, 19 Duckwall discloses the bogus ack packet (see col 6 lines 20- 
50 "According to the P1394 standard, acknowledge packets are eight bit long. . .data 
packets are at least sixty-four bits long. ..count the number of bits. ..discriminate between 
data packets and acknowledge packets. . .equal to eight, the node identifies that an 
acknowledge packet has been transmitted. . ."). 

Furthemore, for claim 34, 46, Duckwall discloses the false acknowledgement packet (see 

col 6 lines 20-50 "According to the PI 394 standard, acknowledge packets are eight bit 

long. . .data packets are at least sixty- four bits long... count the number of 

bits... discriminate between data packets and acknowledge packets. . .equal to eight, the 

node identifies that an acknowledge packet has been transmitted. . ."). 

Furthemore, for claim 39, Duckwall discloses the false response packet (see col 6 lines 

20-50 "According to the P1394 standard, acknowledge packets are eight bit long. . .data 

packets are at least sixty-four bits long.. .count the number of bits. ..discriminate between 

data packets and acknowledge packets. . .equal to eight, the node identifies that an 

acknowledge packet has been transmitted. . ."). 

Hauck and Duckwall are silent about: 
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For claim 4, 19, 34, 39, 46 wherein concatenating the packet is performed by PHY 
hardware. 

For claim 5, 35 wherein link hardware is unaware that the PHY hardware performs 
concatenation. 

Duckwall from the same or similar field of endeavor discloses a communication network 
with the following features: 

For claim 4, 19, 34, 39, 46 Duckwall discloses wherein concatenating the packet is 
performed by PHY hardware (see section 0074 "concatenation in the phy"). 
For claim 5, 35, Duckwall dicloscs wherein link hardware is unaware (sec section 0066 
"is hidden from the link layer") that the PHY hardware performs concatenation (see 
section 0074 "concatenation in the phy"). 

It would have been obvious to one of the ordinary skill in the art at the time of the 
invention to modify / combine the system of Hauck and Duckwall by using the above 
recited features, as taught by Duckwall, in order to minimize arbitration delays (see 
sections 0013-0016) 

5. Claim 6, 7, 21, 22, 36, 37, 41, 42, 47, 48 rejected under 35 U.S.C. 103(a) as being 
unpatentable over Hauck et al. (US 6,356,558) in view of Duckwall (US 5,495,481) as applied to 
claims 1/18/31/38/73 above, and further in view of Kobayashi et al (US 2003/0179719) 

For claims 6, 7, 21, 22, 36, 37, 41, 42, 47, 48 Hauck and Duckwall disclose the claimed 

invention as described above. 

Huack and Duckwall are silent about: 



Application/Control Number: 10/728,185 Page 22 

Art Unit: 2416 

For claim 6, 21, 36, 41, 47 inspecting a first quadlet of a packet to determine a packet 
type. 

For claim 7, 22, 37, 42, 48 the first quadlet contains a transaction code, further 
comprising: determining from the.transaction code that the packet is a stream packet; 
and determining that transmission is not occurring during an isochronous period . 
Kobayashi from the same or similar field of endeavor discloses a communication network 
with the following features: 

For claim 6, 21, 36 , 41, 47 Kobayashi inspecting a first quadlet (see Figure 17 "tcode", 
tcode is in the first quadlet) of a packet to determine a packet type (see section 0264). 
For claim 7, 22, 37, 42, 48 Kobayashi wherein the first quadlet contains a transaction 
code (see Figure 17 "tcode", tcode is in the first quadlet), further comprising: 
determining from the.transaction code that the packet is a 

stream packet (see section 0264); and determining that transmission is not occurring 
during an isochronous period (see section 0264, it is determined transmission is in an 
asynchronous period, which means it is not in a isochronous period). 
It would have been obvious to one of the ordinary skill in the art at the time of the 
invention to modify / combine the system of Huack and Duckwall by using the features, 
as taught by Kobayashi, in order to provide full compliance with the IEEE 1394 is met 
and a method for allowing to easily detect the transfer rate available between two or 
more electronic devices without requiring complex analysis (see Kobayashi section 
0010-18). 
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Conclusion 

THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to KENAN CEHIC whose telephone number is (571)270-3120. 
The examiner can normally be reached on Monday through Friday 8:00-5:30. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, KWANG BIN YAO can be reached on (571) 272-3182. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/Kenan Cehic/ 
Examiner, Art Unit 2416 



/KWANG B. YAO/ 

Supervisory Patent Examiner, Art Unit 2416 



